by William R. Beem
The concept of Internet security is almost an oxymoron. The purpose behind the Internet is to provide an open communication platform among a cooperative collection of users. The Internet's designers' main purpose was not to protect or conceal information, but rather to publish and share it. No regulating body or government has absolute control over who can access the Internet. Anyone can enter it as a user or provider. Any computer attached to the Internet is almost an open invitation for visitors to peek inside.
This model of universal, unrestricted access served Internet users well for many years. The fairly recent commercialization of the Internet brings forth an entirely new set of users with different objectives, concerns, and strategies. Their entry also brings forth a heightened sense of overcrowding, and with it, a need for privacy. The increasing number of personal computer users brings, unfortunately, increasing occurrences of computer crime. Given this increase of criminal activity, it's only natural that commercial entities on the Internet want to protect their assets.
The same is true for individual users who want to practice legitimate, lawful commerce on the Internet. These users see the Internet as a place to gather and exchange information, and also as a new way to purchase products and services. By using current Internet technology, a company can provide information about its specific products to any consumer at any time. Current credit card transaction technology makes it possible for users to send their credit card numbers over the Internet and receive their purchase almost immediately. Attracted by advertising and the ease of buying items with a credit card, consumers are easily lured into making immediate, impulsive purchases. The immediacy of electronic communication thus becomes a strong enticement to buy a product now! Some software publishers are already using this technology to sell and distribute their products and upgrades. Others will surely follow the trend and create a new distribution channel.
Though it sounds nice, this online marketplace has the same dangers as the real world. A criminal who knows that you have money will feel compelled to relieve you of its burden. Consider this scenario. The mechanism that sends your money to a vendor is like a robot. It knows that its job is to carry an amount of money from your account to a vendor. It's feasible for a criminal to create a robot of his own that either disguises itself to look like the vendor, or just plain beats up your robot. Either way, it takes your money.
Commerce is fast becoming the driving force for Internet programmers and Web page designers. Organizations interested in protecting their assets hire programmers who understand the needs of commercial enterprises and how to protect them with security techniques. As a VBScript programmer, make sure you understand this concept. Your purpose is to serve the motivating interests of your employer. Most likely, that interest is commerce. Show your employers, or prospective employers, that you know how to conduct business in a safe and secure manner.
Suppose that a computer vendor posts a Web page that enables consumers to custom tailor their new computers with specific peripherals, software, and other accessories. To a customer, this idea is intriguing. Now, add security to the Web page and the concept changes from intriguing to a viable incentive for the customer to place an immediate order with a credit card transaction. Adding security helps assuage a customer's fears of some unscrupulous person stealing a credit card number as it travels across the Internet. By eliminating the customer's fear of compromising credit card security, you help the vendor establish an impulse buying center for a several thousand dollar computer system. As this concept becomes more accepted in online commerce, the number of vendors seeking developers capable of implementing secure transactions will rise.
Two types of people have an interest in Internet security: those who must protect information and those who want to get it. You can probably learn more valid security information from the criminal hackers than from security professionals. After all, the hacker likes to disseminate information, whereas the security professionals prefer to conceal information. Keep this in mind when browsing the Internet for additional information about security. This chapter provides information on the prevalent Internet security topics in action today, and those in the design stages for tomorrow.
A transaction is the process of conducting business. In most cases, such a transaction involves moving something of importance from one location to another. The amount of security that you choose depends on how much value is attached to the items involved in the transaction. If you're sending a message to someone else, the value that you place on the message determines whether you send an open postcard, a letter in a sealed envelope, or perhaps a package with a dedicated courier service. The degree and type of transaction security that you use for sending data over the Internet is much the same as sending a letter.
Most electronic mail (e-mail) is much like a postcard. It travels from one location to the next, stopping at various points along the path. Any network administrator could read your message without any resistance or any way for you to detect that it is being read. Should such indiscriminate access to data be unacceptable to you or those to whom you send the data, you might find yourself in need of transaction security.
Before deciding on a method of transaction security, it helps to define the elements necessary to secure a transaction. The following list may help you decide what's best for your situation:
This following sections in this chapter discuss how encryption technology helps you achieve these goals in your own applications.
Encryption is the process of transforming a message so that only the intended receiver can restore the message to its original, readable form. A random pattern can easily scramble a message. However, the problem with random patterns is that because of the unpredictable nature of the scrambling process, nobody, not even the message's originator, knows how to unscramble the message so that the receiver can use it again. A valid scheme must use a regular pattern to encrypt the message so that the receiver can decrypt it. However, such a scheme must retain some secrecy so that others cannot decrypt the message.
Regular encryption patterns are called keys. The size and type of a key determines how difficult it is for someone to crack the encryption code and reassemble the message. Keys are bit codes. A computer can easily perform a repetitive search until it finds the correct key to decode the encrypted message. The longer the bit code, the more difficult and time-consuming it is to crack it. The shorter the bit code, the easier it is to crack, especially with the assistance of modern computer technology. Many Internet servers use only 40-bit keys that, although difficult to decipher, are still vulnerable to decoding. A larger bit code increases the number of possible bit combinations and therefore greatly diminishes the likelihood of unauthorized access. Some products use a 128-bit key to make unauthorized decryption practically impossible.
To calculate the number of possible bit combinations in a given set of bits, raise 2 to a power X, where X is the number of bits in the set. For example, a 2-bit set has four possible combinations because 22 = 4. The possible combinations are (in binary notation) 00 01 10 11. An 8-bit set has 256 possible combinations because 28 = 256. A 40-bit set has 1,099,511,627,776 possible combinations because 240 = 1,099,511,627,776.
The United States government considers encryption schemes to be a form of munitions. Therefore, the exporting of encryption-capable applications falls under heavy scrutiny. The government allows as much as 40-bit key encryption for export. Any key using an encryption over a 40-bit code must remain within the United States. Violation of this policy is subject to criminal penalty.
There are two types of keys: symmetric and asymmetric. A symmetric key is one in which the sender and receiver use the same key to encrypt and decrypt a message. Using only a single key is the major weakness of symmetric key encryption schemes. In a symmetric key encryption scheme, the key code must travel unencrypted so that the receiver can use it to decrypt the message. If an attacker gets this key code, he can decrypt your messages, regardless of how many bits you have used to encrypt them.
The United States government defined and endorses the Data Encryption Standard (DES), which is a symmetric, secret-key encryption scheme. Both the sender and receiver must know the same secret key code to encrypt and decrypt messages with DES. The DES standard operates on 64-bit blocks with a 56-bit key. DES operates rather quickly and works well for encrypting large data sets. So far, no one has ever broken into a DES-encrypted file, although many researchers have tried. A pair of researchers proposed a theory that could break the DES encryption scheme, but they still consider DES a secure standard due to the resources and time required to crack a DES-encrypted file. One of these researchers, Adi Shamir, is also one of the creators of the RSA public-key encryption system. The section "RSA Encryption," later in this chapter, covers that encryption system.
Asymmetric key encryption schemes use a public and a private key. Anyone who wants to receive an encrypted message must have both keys. The receiver provides the public key, and the sender then uses it to encrypt the message. The only way to decrypt the message is with a combination of the receiver's public and private key. Even the sender can't decrypt the message, because the sender doesn't know the receiver's private key. Asymmetric encryption schemes soon turn into a web of public keys. In small groups, this process is reasonable, but it becomes unmanageable in large environments with many users.
Imagine you're in a group with five users. Each has a public key. In order to exchange encrypted documents, you need to have the public key of every user. That draws a line from you to user 1, another to user 2, and so on. Now, each of those other users has exactly the same situation, drawing lines from themselves to other users. One user ends up holding multiple keys, and must know which one to use when sending an encrypted document to someone else. Now, multiply that by a 5000 user corporation and imagine the chaos.
If you have any doubt that electronic commerce drives the need for Internet security, this section should open your eyes. The Secure Electronic Transactions (SET) protocol is a combined developmentùincluding Visa, MasterCard, Netscape Communications, IBM, Verisign, SAIC, Terisa Systems, GTE, and Microsoftùthat provides a method to secure bankcard transactions over open networks such as the Internet. Previously, these organizations were working on separate technologies to perform the same basic task. You may find old references to Secure Transaction Technology or Secure Electronic Payment Protocol. Many of the overview details seem similar, but the implementations varied. Fortunately, for both developers and consumers, these groups decided to pool their talents to create a single technology designed to secure transactions conducted on public networks.
Visa and Microsoft developed STT as an open specification for the industry. Meanwhile, MasterCard, IBM, and others worked on another open specification for the industry: Secure Electronic Payment Protocol (SEPP).
On February 1, 1996, MasterCard International and Visa International joined together to announce a technical standard for safeguarding payment-card purchases made over the Internet. They call the new specification Secure Electronic Transactions (SET), which combines both efforts.
Earlier sections of this chapter discussed the growing trend of electronic commerce and the need for secure financial transactions. Breaking into an encrypted file is a daunting task, and people always take the path of least resistance. Cracking an encrypted transaction is the modern equivalent of blowing up the bank to steal its money. To say the least, it's not subtle. A criminal must decide if the contents are worth the effort. If the prize inside an encrypted file is nothing more than a collection of movies in AVI format, it's probably not worth the effort required to crack the file. If the prize is a financial transaction, the criminal may decide to expend some time and effort to steal money or credit card numbers.
Suppose that an attacker wants to steal your funds. Instead of attacking your secure file, he may instead set up a Web server that claims to represent a legitimate business. With a little creative programming, the attacker's site can let you browse an electronic catalog of goods. After you decide to make a purchase, you engage your super-secret encryption scheme and send off a payment to the server. After a nice run of collecting credit card numbers, the server closes down. You're left anxiously awaiting a package that never arrives. As you wait, the attacker is trashing your credit history. This kind of nightmare is exactly what bankcard holders want to avoid. They already spend millions of dollars to combat credit card fraud.
With the aim of fighting such scams, SET has the following objectives:
Bankcard providers certainly want to encourage commerce on the Internet. An analysis of past mail order and telephone order transactions shows that customers strongly prefer paying with bankcards rather than with checks, wire transfers, or any other type of payment. Credit cards fit better with the nature of electronic communications than any other payment medium.
The SET protocol specifications, like other security specifications, can address only a portion of the protocols necessary for electronic commerce. Standard Internet protocols (such as TCP/IP and HTTP) already exist to provide the transport mechanism, communication services, and application interface necessary for commerce. STT differs from the protocols previously discussed in this chapter in that it concentrates exclusively on the security aspects that pertain to bankcard transactions. The following aspects of bankcard transactions are within the scope of the SET protocol:
Clearing and settlement is the process by which a merchant receives payment for a transaction using a bankcard. The merchant authorizes the transaction and then later requests payment from the cardholder's financial institution. Merchants who use the Internet for commerce are subject to the same credit card fraud dangers that occur in other purchase sources, such as telephone orders.
The clearing and settlement process differs depending on the card used and the relationship defined between the merchant and the financial institution. As such, SET does not modify the clearing and settlement process. The merchant is responsible for clearing and settling electronic commerce transactions in the same manner in which it processes other transactions. The clearing terms depend upon the merchant's agreement with its bank.
SET brings forth a new application of digital signatures by requiring dual signatures. Electronic commerce requires two sets of authorizations. Suppose that you want to send an offer to a vendor to buy an item. You include a digital signature to authenticate yourself as a customer and otherwise validate the message. The same time that you send your message to the vendor, you send another message to your financial institution that authorizes it to release the funds that you specify if the vendor accepts your offer. You need not disclose the details of the offer to the financial institution. All the financial institution needs is your instruction to release funds if it meets a specified condition.
To process the offer automatically, the vendor sends a request for payment, including your digital signature, to your financial institution. The financial institution matches signatures. If it verifies that both are the same, it transfers the funds to your vendor. The transaction, from a financial perspective, is then complete.
A dual signature concatenates the message digests from your letters to the vendor and the financial institution. SET then computes another message digest from the concatenated result and encrypts it with the signer's private signature key.
One key element necessary for authorization is a credential for cardholders and merchants alike. The financial institution provides a credential for cardholders. In theory, you cannot alter these credentials and only the financial institution can generate them. Likewise, the merchant's financial institution issues the merchant's credential.
A credential in this case is a binary file that acts as the bank's seal of approval for financial transactions. The binary file is actually a digital signature like those discussed earlier in the chapter.
RSA is an algorithm for asymmetric encryption. Named after its inventors Ron Rivest, Adi Shamir, and Leonard Adleman. The algorithm, owned by Public Key Partners (PKP) of Sunnyvale, California, received a patent in 1983. RSA's use is subject to the approval, and possible license, of its owners. Anyone in North America must obtain a royalty-based license from PKP to use the RSA algorithm in a commercial endeavor. Fortunately, PKP usually allows free non-commercial use of RSA for personal, academic, or intellectual reasons, with written permission. The United States government can use RSA without a license, because the algorithm was developed at the Massachusetts Institute of Technology (MIT) with some government funding. The patent does not apply outside North America.
RSA is well established as a de facto standard. As the most widely implemented public-key encryption system, it is a safe choice for implementing encryption schemes in applications. RSA's common use makes it easier to exchange digital signatures. This standard is entrenched in the financial transaction protocols being developed for electronic commerce. This endorsement alone confirms that RSA carries much weight as a secure standard.
RSA is a complement to, rather than a replacement for, DES encryption. Each scheme has benefits that the other lacks. DES is a fast encryption scheme and works well for bulk encryption. Although RSA is fine for encrypting small messages, DES is a better choice for larger files because of its speed. RSA provides digital signatures and secure key exchange without requiring a prior exchange of secret codes.
A single user protecting files for personal use probably doesn't need RSA. For such use, a single-key encryption scheme like DES usually suffices because there's no danger involved in passing the key to anyone else. RSA becomes important when you must share messages with others.
Combining the two encryption schemes is like sending a coded message in a secure envelope. A typical RSA digital envelope transaction with another party might operate as follows:
1. Encrypt the message with a random DES key.
2. Encrypt the DES key with RSA.
3. Send the combined DES/RSA encrypted document through the Internet.
As mentioned before, RSA also creates digital signatures. When authentication is as important as concealment, you must use RSA in place of or in conjunction with DES encryption.
RSA starts with two large primes: p and q. The product of p and q is n, the modulus. You might find some documentation pertaining to RSA that recommends choosing a key pair with strong prime numbers. A strong prime is one with properties that make the product (n) hard to factor with certain methods.
A modulus is the mathematical process of dividing two operands and returning the remainder.
Factoring is the process of splitting an integer into a small set of integers (factors) which, when multiplied, yields the original integer. Prime factorization requires splitting an integer into factors that are prime numbers. Multiplying two prime integers is easy, but factoring the product is much more difficult. That's why prime integers are such prize candidates for encryption schemes. Reversing the process of multiplication using prime numbers is extremely difficult. This is called a one-way function, one that is easy to perform in the forward direction, but far more difficult to compute in the inverse direction.
Due to new factoring methods, the common knowledge method of choosing strong primes is no longer an advantage. The new methods have just as much success on strong primes as with the weak ones.
Another concern with choosing your primes is the size of modulus that you want. There's a bit of a trade-off: a larger modulus creates a more secure encryption scheme, but also slows the encryption process. Choose your modulus length based on your security needs, or perhaps based on the resources that an attacker may use to crack your encrypted message. Here's some research trivia to help guide your decision: Rivest's estimates suggest that an attacker can factor a 512-bit modulus with an $8.2 million effort. If you require a 512-bit modulus, each of your primes should be approximately 256 bits long.
Next, choose a number, called e, that is less than the value of n and also relatively prime to (p-1)(q-1). Next, find its inverse value, d, (mod(p-1)(q-1)). That means that (ed = 1 mod(p-1)(q-1)).
The variables e and d are, respectively, the public and private exponents. The public key pair is (n,e). The private key is d. You should keep factors p and q confidential, or else destroy them.
Before you start writing your own code, pay attention to this next part, because it reveals the Achilles heel of RSA encryption.
Trying to determine the private key (d) from the public key combination (n,e) is practically impossible. Now look at those variables (p and q) that you want to hide or destroy. If you factor n into p and q, you can discover the private key (d).
The following list shows you how the RSA encryption algorithm flows step by step:
1. Create two variables, P and Q. Create another variable, N.
2. Choose two large prime numbers and assign one to P and the other to Q.
3. N is the modulus of P and Q (n := P mod Q)
4. Create a variable, E.
5. Choose a number to assign to E that is less than the value of N and also relatively prime to the results of the formula ((P-1) (Q-1)).
6. Create a variable, D.
7. Find the inverse value of E with the formula (mod(P-1) (Q-1)). Assign that value to variable D.
Keeping in mind how much an attacker would love to have your p and q primes, carefully consider which method to use to generate primes. If you select a predictable pattern, an attacker might duplicate it and render your machinations useless. It's best to obtain random numbers from a physical process. Although some computers use dedicated peripheral cards just for this purpose. One example is the FedWire II system used by many U.S. banks. FedWire II is an encrypted communication network that performs monetary wire transfers between banks and the Federal Reserve. You probably want a less expensive solution. Try timing some of the various input devices connected to your computer (such as your mouse, keyboard, or serial device) and use the time difference between inputs as a random number generator. If you choose an algorithm based on a random seed, try to select a seed that isn't obvious to someone who can duplicate your efforts, or at least select a seed that is truly random.
RSA authentication is a specific method for creating a digital signature. A digital signature holds a unique advantage over a handwritten signature. With a handwritten signature, you can alter a document's contents without invalidating the signature. You cannot do this with a digital signature, because the document's contents comprise the digital signature itself.
A digital signature failure doesn't always mean that someone tampered with your document. If you are transmitting the document over the Internet or other network lines, a digital signature failure may also suggest a corrupted file transfer.
You obtain your digital signature from a message digest. A message digest is the result of a hash function. A hash function is a mathematical algorithm that reads some input data source, usually a message or some kind of document, and returns a compact binary output that represents the source. Some other types of programs, like databases, use hash functions as an index to the data source for quick searches.
A hash function uses a variable-size input and returns a fixed-size string, called the hash value.
Hash functions that are difficult to invert are specifically useful for creating message digests. A message digest is a concise representation of the message used to create the digest. Any change in the message itself yields a different message digest string, thus making it useful as a digital signature.
Several well-known message digest functions are in use, but MD5 is perhaps the best function to implement as a digital signature. MD5 is secure, reasonably fast, and publicly available for unrestricted use.
ON THE WEB
http://ds.internic.net/ds/dspg0intdoc.html For more details on the MD5 function, see RFC 1321 at this Web site.
One significant issue with digital signatures is a legal matter rather than a technical one. Digital signatures may not have the same legal status as a handwritten signature. No one has yet challenged the validity of a digital signature in court, so there is no legal precedent. The National Institute of Standards and Technology (NIST) has, however, requested an opinion from the United States General Accounting Office (GAO) regarding the legal status of digital signatures. The GAO opinion is that digital signatures meet the legal standards of handwritten signatures.
Authentication is a process that assures a document's recipient of the sender's validity and the document's integrity. The authentication process verifies that a transaction is original and unmodified. The process yields a digital signature created from a message digest, which is a unique string of bits based on the message's contents. A signature is an unforgeable data string that testifies that a specific person created or agreed with the document's contents. A sender creates the message digest and encrypts it with a private key. The message digest accompanies the message. The receiver decrypts the message digest and compares it to the message. If the two agree, the authentication process is valid. You can encrypt and sign a message at the same time.
Another authentication process relies on digital certificates. These digital certificates contain the following:
The CA is a trusted authority, such as VeriSign, that creates digital certificates. The CA generally charges for this service. A CA publishes its public key and Distinguished Name for other people to add to Web browsers or servers as part of their trusted root. Users who want to authenticate a digital certificate use the CA's public key to verify the CA's signature in the certificate.
As Microsoft started providing Internet development tools, it realized that programmers creating sophisticated communications software needed an application programming interface (API) to provide encryption and secure communications. The result is CryptoAPI, an API that allows Win32 developers to include cryptography technology in their applications. Its goal was to create an API that made cryptographic application development functional, flexible, usable, and exportable for Windows developers.
The CryptoAPI uses a modular approach. The actual cryptographic operations are performed by replaceable components known as cryptographic service providers (CSPs). CSPs are dynamic link libraries with associated cryptographic signatures authorizing it for use by the CryptoAPI. Each CSP contains the cryptographic algorithm, but is developed independently of the application. This means your applications can run with many different CSPs, allowing you to choose a CSP that fits the level of security you need without having to modify your application code.
The CryptoAPI provides the following services:
CryptoAPI provides 24 function calls contained under five categories, as follows:
Context management functions connect an application to a CSP. The functions let your applications choose a specific CSP by name, or choose a CSP with a specific functional class.
Key generation functions let your applications generate and customize cryptographic keys. You can randomly generate keys or derive them from a password. The functions include support for changing initialization vectors, chaining modes, and other encryption features.
Key exchange functions allow your applications to exchange or transmit keys. Encryption keys transmitted outside the CSP are themselves encrypted with the user's public key. They remain so encrypted until they reach the destination user's application. This allows you to transmit keys without compromising them as a security breach to your own encryption techniques. You can use these key exchange functions to implement Private Communication Technology (PCT) or Secure Sockets Layers (SSL) technologies in your own applications.
The Data encryption and decryption do much as the titles suggest; they allow you to encrypt and decrypt data. The functions also include support to simultaneously encrypt and hash data.
The Hashing and Signature functions allows your applications to compute cryptographically secure message digests based upon data. They also enable you to include digital signatures based upon those message digests. Once signed, anyone possessing the signer's public key can easily verify the signer's identity, or whether something modified the data file.
Microsoft licensed its cryptographic technology from RSA Data Security to create the default CSP that will ship with its Win32 operating systems. This CSP supports both public-key and symmetric cryptography. The first version should ship with the Windows NT 4.0 operating system, and then later with a future version of Windows 95. You can find the Microsoft CryptoAPI on Microsoft's Internet Development Toolbox Web site.
Encryption is an age-old technology that works quite well. Its application in electronic commerce is still in its infancy, however. Each of the Internet security specifications discussed in this chapter is still under revision. Some products, particularly those from Netscape and Microsoft, already implement the concepts, even though the specifications are nothing more than working drafts. Perhaps that's why people still don't trust their cards to these schemes.
Nevertheless, the market for such technology continues to grow. If you're a programmer who works as an independent contractor, this is an excellent field to enter on the ground floor. With billions of dollars in purchasing power at stake, vendors clamor for space on the Internet. As this happens, they spend a lot of money on developers who can ensure the safety of their dollars, as well as that of their customers.
In the meantime, here are some Web sites that may help you find more information:
In this chapter, we took a bird's eye view of Internet security concepts and techniques. You can browse some of the Web pages listed previously for more information on security topics. After that, perhaps you'll want to try your hand at implementing security in some of the protocols discussed in other chapters of this book.
| Previous Chapter | Next Chapter |
| Search | Table of Contents | Book Home Page | Buy This Book |
| Que Home Page | Digital Bookshelf | Disclaimer |
To order books from QUE, call us at 800-716-0044 or 317-361-5400.
For comments or technical support for our books and software, select Talk to Us.
© 1996, QUE Corporation, an imprint of Macmillan Publishing USA, a Simon and Schuster Company.